In previous system configurations system dependent information (such as the number of CPUs and memory available) was statically and redundantly distributed across the cluster. Each node was manually, individually configured with this static system dependent information. Accordingly, when more memory was added to the system each node had to be manually updated to reflect that. The programmer therefore not only had to know what nodes where on the system, but where they were stored (the path) and the proper syntax for defining each node properly.
FIG. 1 illustrates an exemplary system of multiple physical machines. Each physical machine 101, 115 of the system 129 includes at least one instance 103, 113, 117, 119 and node 105, 107, 109, 111, 121, 123, 125, 127. Of course, a physical machine 101, 115, such as a server, developer computer, or personal computer, may have multiple instances 103, 113, 117, 119 with each instance having more than one node 105, 107, 109, 111, 121, 123, 125, 127. In a physical machine utilizing a Java runtime environment, the nodes are Java containers such as J2EE, servlet, etc.
Additionally, each physical machine 101, 115 commonly had different hardware and software components that were not compatible with other physical machines in the system. With each node individually configured to fit a particular machine's setup, it was nearly impossible to move a configuration (as is) from one physical machine to another. For example, if the configuration for a machine_1 101 includes 1024 MB of memory, runs a Microsoft Windows operating system, and a SUN virtual machine one could not simply port this configuration to a machine_2 1115 that has 512 MB of memory, runs a Linux operating system, and uses a IBM Java virtual machine.
When a change was made a machine in a system, nodes where changes should be applied had to be restarted. The VM settings changes will take place only after restarting the whole instance, which can lead to downtime only if the system has only one instance. In many business environments (for example, web services), this downtime can cause not only user frustration at not being able to access needed information or programs, but loss of income for the duration of the machine being offline.
Additionally in prior scenarios, Java parameters were stored in one single property. All child configurations would hide the parameters of their parents, as the child completely overwrites its parent's property. Accordingly, in the single configuration scenario, if the parent's property changed, there would be no way of propagating that change to the child.
A cluster is a group of at least one system. A bootstrap synchronizes the components in the file system (FS) of a cluster. Prior J2EE engine versions stored the information about FS archives deployed in the cluster on the file systems of the cluster nodes. Many times the data on the FS was deleted and it could be restored only by redeployment.